Is there any known negative consequence to doing this?

Is there any known negative consequence to doing this?

I'm not aware of any. Trino is a bit special than other tools as it refuses to start up for any unneeded property

It feels weird to have this "seem" so unrelated to configOverrides.. how about something like:

apiVersion: trino.stackable.tech/v1alpha1
kind: TrinoCatalog
spec:
  connector:
    hive: {}
  configOverrides:
    hive.metastore.username: trino
    property.which.blocks.trino.startup: null # <<< removes field

Another option would be to follow your proposal for v1alpha1, but switch to something like this in v1alpha2:

apiVersion: trino.stackable.tech/v1alpha2
kind: TrinoCatalog
spec:
  connector:
    hive: {}
  configOverrides:
    set: # <<< was configOverrides
      hive.metastore.username: trino
    remove: # <<< was experimentalConfigRemovals
      - property.which.blocks.trino.startup

Yeah, exactly

This field is experimental, as ideally some general solution for the removal of properties is found and added to configOverrides. This mechanism would replace this field.

IMHO we need this solution for all operators, which is a big task I don't want to do right now.
The current proposal is a quick temporary solution until we figured out the "correct" way of doing it.
I was also thinking of null being special, however that would cause trino-op to have a different behavior as all other operators, which is also not great.

Moving this to Voting, please vote on this comment

Decision accepted in planning

Please add a link to the docs and a release note snippet.

Docs: https://docs.stackable.tech/home/nightly/trino/usage-guide/catalogs/#_config_overrides_and_config_removals
Release notes (I don't think it's important enough for the SDP release notes, but let others decide):